ソフトウェアアーキテクチャの基礎輪読会 6章
日付：11/9
調査者：ichimura.icon
どんな内容が書かれているか
要約
パフォーマンスを例に挙げて、アーキテクチャ特性の曖昧さを知る
そういった曖昧さを持つアーキテクチャ特性は客観的定義をすることでチームで共有できる
統制のための適応度関数は自動化されたものが多くある 一般的なアーキテクチャ特性のいくつかを具体的に定義し、それらを統制する仕組みを構築することに焦点を当てる
アーキテクチャ特性
アーキテクチャ特性を議論する際に問題になる要素
形が決まっていない
一般的に使われている見解が曖昧
組織によって定義がさまざま
複合的すぎる
ex. アジリティ
モジュール性
デプロイ容易性
テスト容易性
こうした問題を避けるため、アーキテクチャ特性の客観的定義を持とう！
どうやって？ → 複合的な特性を紐解いて、計測可能かつ、具体的な特性を見つける
6.1.1 運用面の計測
アーキテクチャ特性では明確で直接的な計測を伴うものが多い
しかし、そうした特性であっても、チームの目標に応じて、多くの曖昧な解釈が生じうる
ex. リクエスト応答速度、
パフォーマンスの多様な意味
処理能力
リソース効率
適応性
統計分析に基づいたパフォーマンス目標値を定めていけると強そう
各モバイル端末でのパフォーマンス問題が常に付きまとう
ichimura.iconモバイル端末っていうのは、単にそれぞれの環境での読み込み速度や端末自体のスペックによる読み込みやレンダリングの違いのことと認識している
コンテンツの初回ペイント
CPUの初回アイドル
6.1.2 構造面の計測
パフォーマンスほど明確でない客観的尺度もある。
しかし、汎用ツールを使えばコード構造の重要な側面のいくつかに対処できる
循環的複雑度とは
客観的尺度を提供するために設計されたコードレベルのメトリクス
計算式がある
CC = E(エッジの数) - N(ノードの数) + 2(?)
Cyclomatic Complexity
takasshii.iconノードが条件分岐、エッジはなんだっけ？
iNoma.iconZOZOTOWNの技術ブログでkotlinにおける計測について触れてる
takasshii.icon👀
code: HogeComponent.kt
@Composable
fun HogeComponent(
c1: Int,
c2: Int,
){
if (c1 < 100) {
Text("0")
} else if (c1 + c2 > 500){
Text("1")
} else {
Text("-1")
}
}
この例の循環的複雑度は3 - 2 + 2 = 3
ichimura.iconエッジとノードについて、あまり理解できていない
一般的に、CC ≤ 10であることが推奨されている
本書曰く、10まだ大きくて５が望ましいらしい
6.1.3 プロセス面の計測
アーキテクチャ特性の中には、ソフトウェア開発プロセスと交わるものがある
極論、3章モジュール性にある3つの基準を満たしていけばアーキテクチャ特性として引き上げられる可能性がある。
6.2 統制と適応関数
ソフトウェアプロジェクトでは緊急性が注目されがちだが、そうで無い重要なものを重視するために統制の仕組みが必要である。
ex. モジュール性
6.2.1 アーキテクチャ特性の統制
アーキテクトが影響を与えたいソフトウェア開発プロセスのあらゆる側面が、アーキテクチャ統制の範囲に含まれる。
6.2.2 適応度関数
アルゴリズムを誘導する仕組みが適応度関数と呼ばれている
ex. セールスマン問題
3つの適応度関数が考えられる
ルートの長さを評価する適応度関数
コストを最小限に抑えるための、ルートに関連する全体的なコストを評価する適応度関数
総移動時間の短縮に最適化するための、セールスマンの巡回中時間を評価する適応度関数
アーキテクチャ適応度関数
あるアーキテクチャ特性またはアーキテクチャ特性の組み合わせについて、客観的な生合成評価を行うための何らかの仕組み
よくわかんないです。ただ、アーキテクチャを進化させていく仕組み
takasshii.icon1章には最適解に近いか遠いかを判定する関数って書いてあったな
ichimura.icon 👀
Null Safetyへの対応度合いを測定する関数のことを適応度関数と呼んでいるブログがあった
https://scrapbox.io/files/654c1ed0455717001cd57a86.png
takasshii.icon最適解が何になるかによって評価関数は変わってきそうね
適応度関数の例を紹介
6.2.2.1 循環依存
モジュール性が失われるコンポーネントの例が紹介されている
IEDの補完機能で、安易な自動インポートをするとこういった相互参照の状態を作る恐れがある 対策できるツールがあるらしい
これで循環依存があると、テストで失敗するようになるらしい
takasshii.iconマルチモジュールだとGradleでエラー出るよね
6.2.2.2 主系列からの距離を測る適応度関数
3.2.2 結合度で紹介されていた主系列からの距離を測る適応度関数
さっきのツールに距離のしきい値を設定することで、クラスが範囲外であるときテストが失敗するようになっている
特殊な目的のもの
java用のフレームワーク
“モジュール性に対応した特定のテストを書けるようになっている”